Contemporary network device communication systems may provide responses using structured electronic documents, such as XML documents. A user may retrieve the configuration of a network device by issuing a request, and the network device responds with an XML document that contains its then-current configuration. Responses, such as XML documents, from network devices are often of a large size, which may lead to increased burden on client, the network device, and the network itself. Further, in some environments a network device, server, or other element that stores and delivers a large XML document as a response, has limited memory available for storing the document. To address these issues, having a way to break up large response documents is desirable.
One approach to solve this problem is to use a transport dependent mechanism that can communicate documents in chunks, such as Blocks Extensible Exchange Protocol (BEEP). In this approach, if both communicating parties (e.g., the client and the network device) support the transport protocol that implements BEEP, a first party may request and receive only a portion of a communication from the second party. However, both parties must be configured to communicate using the transport protocol and BEEP. As most networks today are evolving at an accelerated pace and consist of a variety of clients and network devices, it is undesirable to require each client and each network device in the network to be configured to communicate using a specific transport protocol, as it may be impossible or impracticable for one or more clients and/or network devices to be configured to communicate using the specific transport protocol. Further, BEEP requires that the entire XML response is created or known in advance of transport.
In another approaches, a receiving client provides instructions for retrieving data in portions. The client instructions specify a range of desired data or a set of desired portions for retrieval. When those portions are retrieved, the client provides further instructions to retrieve the next portions in order. However, in these approaches, the client needs to know the contents or structure of the data it is retrieving, and may need to calculate how many items the client can retrieve at once. The client may also need to know the names of items that are retrieved. Further, in most approaches, there is no potential for a responding network device or server to break up a response when the network device or server knows that the receiving client will need a relatively long time to process the response.
Another problem encountered when configuring network devices over a network is that the client may use a different version of a data schema for a particular component on the network device than the network device uses for that same component. This may happen when a data schema associated with either the client or the network device is updated without updating the corresponding data schema on the other. When the client and the network device each expect configuration data in a particular data schema to be represented differently, a request from a client to update the configuration using that particular data schema may result in either the operation being unable to be processed on the network device or it may result in the introduction of errors in the configuration of the network device.
One approach in solving this problem is for the network device to associate a version number with an Application Programming Interface (API) that allows the client to communicate with the network device. The client may use the API version number to determine if the commands and requests that client is using are current or out of date. However, this approach is problematic in that the version number applies to the API as a whole, and must be updated each time that there is any change in any way the network device interacts with the client. Consequently, there are many false occurrences of version incompatibility in this approach, as a request from a client using a particular API call with an out-of-date version number may still be compatible, since the call may only invoke functions or software components of the network device that have not changed since that version.
In another approach, exemplified by Simple Network Management Protocol (SNMP), no version numbers are used, but each new version must handle all previous versions transparently. Thus, old functions are not removed, and only new functions are added. However, this approach is problematic because those who develop or maintain a new version also must support all old versions. Further, if a response to a GET request appears to be missing a data element, an application may be unable to determine if the responding network device omitted the element because no data is available, or because that element is no longer supported.
Consequently, there is a need in the art to configure a network device through the exchange of communications without encountering the problems associated with the approaches discussed above. The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.